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Abstract. The ESA Packet Telemetry and Telecommand Standards 
accommodate the requirements of a great variety of scientific space mis- 
sions, thus providing a standard basis for cost-effective and technically 
■ compatible developments of on-board and on-ground data handling sys- 

tems for a wide range of projects. This paper describes the design and 
the implementation of a detector-independent software, running on Unix 
platforms, which has been developed for the near real time acquisition, 
£vq | archiving, and basic processing of the ESA based telemetry and telecom- 

mand data produced during the on ground testing and calibration of 
various X- and 7-ray space borne detectors. 
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Every scientific payload adopting the ESA Packet Telecommand (TC) and Teleme- 
•£3 . try (TM) Standards uses the TC and TM source packet structures in order to 

receive the commands which determine the payload set up and operations, and 
to send the data generated by its subsystems. These standards dictate the guide- 
lines for the packet structure, as formed by an header, a data field and a trailer. 
^ ■ They also state the information to be included in the header and in the trailer 

in order to allow the verification and decoding of the packet content. Among 
them, the Application Identifier (APID) is required to identify the subsystem 
which is the destination or the source of the TC or the TM packet, respectively. 
In addition, for a given APID, the Type/Subtype keywords identify the spe- 
cific operative mode under which the data have been produced, and, then, the 
structure of the data contained in the data field. 

Suitable Electrical Ground Support Equipment (EGSE) hardware and soft- 
ware are required in order to test and verify, before launch, all the payload 
functionality and performances. To this purpose, the EGSE provides the sim- 
ulation of the relevant missing on-board subsystems, generates and sends to 
the payload the TC packets, receives and archives all the TM packets. By in- 
specting in near real time the TM reports and the TM housekeeping packets, 
the EGSE verifies the correct execution of the TC, and is able to monitor the 
payload health, as required to support the basic engineering tests. In addition, 
a big effort is required to the EGSE software developers in order to allow the 
EGSE operator to easily verify all the different scientific operative modes, and, 
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Figure 1. TM and TC packets data flow during ground tests. 



in particular, to verify and calibrate the scientific performance of the detectors 
illuminated with X- and 7-ray sources or beams. 



2. DESIGN CONCEPT 

The use of the ESA TC/TM Standards, allowed us to adopt the common de- 
sign concept sketched in Figure [l], where the EGSE is limited to the engineering 
functionality, while the scientific functionality is provided by the Science Con- 
sole, which receives in near real time, from the EGSE, a copy of all the TC and 
TM packets. The EGSE was procured by the industry, and the Science Con- 
sole software was in charge of the scientific team responsible for the instrument 
acceptance test and calibration. 

The DISCoS (Detector Independent Science Console Subystem) software we 
present in the following sections, is the part of the Science Console software which 
was integrated with various detector specific software written in order to unpack 
the information contained in the TC/TM packets and to perform the quick look 
on the scientific data. The current version, which is being developed for the 
AGILE mission (Trifoglio et al. 2000), profits from the experience gained with 
the previous versions which have been exploited for the XMM-EPIC mission 
(Trifoglio et al. 1997; Trifoglio et al. 1998), and the INTEGRAL-IBIS mission 
(La Rosa et al. 1999; Trifoglio et al. 1999). 



3. SOFTWARE ARCHITECTURE AND IMPLEMENTATION 

The DISCoS software consists of the C programs (Monitor, Receiver, Archiver 
and Provider) which allow the Science Console to acquire, verify and archive in 
near real time the TC/TM packets in one set of files for each measurement setup, 
and to reconstruct, either in live or in playback mode, the various stream of TM 
scientific packets pertaining to the various operative mode, i.e having the same 
APID/Type/Subtype. Figure ^ sketches how these programs interact together 
and with the unpacking programs (Processors) and the quick look programs 
(Quick Look Analysis and Graphical Display) to be written by the DISCoS 
users. 

Once started from a shell script, every second the Monitor updates on a 
screen window the status information and relevant parameters that the con- 
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Figure 2. The Science Console software architecture. 



cerned programs write on the Shmmon shared memory by using specific rou- 
tines. In addition, the Monitor program allows the operator to generates fake 
start/stop TC, to be used by the Science Console in order to close and open the 
measurements files independently from the TC packets generated by the EGSE. 

The Receiver is the program which interfaces the EGSE through a TCP/IP 
or UDP socket on an Ethernet LAN 10/100 BaseT. Once started from a shell 
script, it waits as a Server, and, in the TCP/IP case, establishes with the EGSE 
a stream socket connection. Hence, using a fork the Receiver generates the 
Archiver program. As long as the connection is active, the Receiver performs 
a reading loop. On each iteration, by using a non blocking call it reads from 
the Monitor task message queue the next fake TC packet, if any; and by using 
a blocking call, it reads from the LAN in order to acquire the next TC/TM 
packet. For each packet, the Receiver inspects the header in order to verify 
the Application Identifier (APID), the Source Sequence Counter (SSC) and the 
packet length. Hence, by using a blocking call, the Receiver sends through a 
message queue the packet to the Archiver program, and restarts reading. In case 
a Start/Stop measurement commands is detected, the Receiver waits until the 
Archiver message queue is empty, then it sends a SIGINT signal to terminate 
the running Archiver, forks a new Archiver, and eventually restarts reading. 

Every time is started, the Archiver opens a new set of raw files: one to 
contain all TC/TM packets, and one for the TC and the TM Housekeeping 
only. Their locations and names are automatically derived from the progressive 
number (Run ID) which identifies the measurement. An additional suffix is 
used to identify the files containing the data generated during the instrument 
configuration. By using blocking calls, the Archiver reads each TC/TM packet 
from the message queue and writes each packet on the local disk using low 
level C-Unix Unformatted I/O routines. Upon receiving a SIGINT signal from 
the Receiver, the Archiver completes the reading and archiving of any TC/TM 
packet from the message queue, closes the raw files, and then terminates itself. 

The Provider reads and sorts the TC/TM packets from the raw file. This 
program is run by a shell script either in live or in playback mode. In the former, 
the raw file name is derived from the current Run ID and the forthcoming 
TC/TM packets are read upon receiving the SIGUSR1 signal from the Receiver. 
In the playback mode, the program starts reading from the raw file which name 
has been provided by the script. For each packet, the Provider verifies the 
correctness of the packet header, sorts the packet by APID, and writes the 
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packet in the column of the shared memory Shm assigned to the APID. Indeed, 
this shared memory is managed as a two-dimensional circular buffer capable 
of containing some hundreds of packets for each APID. Information exchanged 
with the Provider, through the shared memory Shms, allows each Processor 
to read new TC/TM packets having the required APID as soon as they are 
available in the shared memory Shm. A synchronization mechanism guarantees 
that no TC/TM packet is overwritten until it has been read by the related 
Processor. Unless a time out is expired, before overwriting the Provider waits 
for a SIGUSR2 signal generated by the concerned Processor to notify that the 
new data have been already read. 

In order to allow the interfacing with the detector specific programs, the 
DISCoS software includes a set of C, Fortran and IDL callable routines. They 
allow the user to write the Processors as separated programs which have access 
to the monitor window and to the various source packet streams sorted by APID, 
without having to deal neither with the EGSE interfacing, nor with the TC/TM 
packet acquisition, verification and archiving. Usually, one Processor program is 
run for each APID. For each sorted stream, the Processor has access to 100% of 
the acquired packets, irrespective of both the input rate and the processing to be 
performed on the packet. A typical Processor reads the TC/TM packets from the 
shared memory Shm, verifies and archives the instrument data extracted from 
the packet data field in a format suitable for further off-line analysis (e.g. FITS 
format). Other DISCoS routines allows the Processor to communicate these 
data, through the shared memory Shmf, to another user's program, written 
in IDL, which is devoted to quick look purposes. Depending on the selected 
mechanism, on each call the quick look program receives the unpacked data 
related to either the next or the last packet processed by the Processor. A 
typical quick look program produces and displays in near real time further data 
products (e.g. time profile, spectra, and images) allowing the user interaction. 

4. CONCLUSIONS 

The DISCoS software presented herein has demonstrated its effectiveness and 
re-usability in the Science Consoles developed for several EGSE and Test Equip- 
ments which have been designed adopting the ESA Packet Telemetry and Telecom- 
mand Standards for the instrument data and commands transport structure. 
The software architecture and implementation has allowed a simple porting from 
the original HP-UX Unix workstation platform to the Linux PC platforms with 
the GNU Compiler Collection (GCC). 
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